The Use of the SAGA Tool for Gathering Requirements for Future Information Systems

Scenarios have been used in many different ways to assist planning. They have been used for over 20 years in technological forecasting for corporate plans, in testing for the suitability of human-computer interfaces, in experimental gaming to explore decision-making processes, in preparing case-studies for management education, and for “surfacing” assumptions underlying strategic planning. One of the more useful applications of scenarios is generating user requirements for information systems. For this application several scenarios could be generated showing pessimistic, optimistic, and most likely cases in order to develop the requirements that are common to all cases, so that a system can be designed for a “surprise-free” future. However, preparing scenarios is often too laborious to allow for more than one or two scenarios to be generated. As well, it is very difficult to ensure that the scenarios are consistent and coherent. This paper describes the SaGa (&enqrio Generator) computer-based tool that easily generates a number of scenarios containing a coherent set of factors. These scenarios can be used to provoke ideas and judgements porn managers about how to achieve theJirture system that they desire. The paper gives the results of using the tool to determine the requirements for information systems for Australian Government agencies. Need for tools for determining requirements This paper describes a scenario-generation tool, called SaGa. that can help systems planners to produce a complete set of requirements for the future use of information resources. This tool overcomes some of the present difficulties with requirements engineering a limited consideration of the full range of requirements and ‘requirements creep’. Unfortunately, there is too much concentration upon the gathering of so-called “user” or “functional” requirements, with neglect of the many other types of requirements that are necessary for the proper preparation of business cases or the design of systems. Display 1 shows the different types of requirements. The system requirements (including the infrastructure and policy aspects) often seem to be overlooked. As well, there is neglect of the acceptability aspects of functional requirements when plans are formed. Most requirements engineering texts suggest the use of interviews or observations, coupled with simple diagrammatic tools for process analysis, to generate a flat list of requirements (Laundon and Laundon [l], Senn [2]). More recently, Group Decision Support Systems (GDSS) have been used to brainstorm a list of desired capabilities. Lewis and Newton [3] describe the use of “Grouputer” in Information Management planning. Others (Nunamaker et al [4] and Dennis et al [S]) describe the use of variants of “GroupSystems“ in systems planning. The list of requirements generated by such methods and tools tends to be a reflection of current practice rather than a projection into the future of the organization. People do seem to find it hard to project their vision more than a year or two into the future, so they provide ideas that reflect what they know rather than what is needed by the time a system is introduced into service (which can be three years for large organizations). Accordingly, there is a need for requirements to be gathered based upon a clear understanding about both what is needed by the business and what is available from technology in the time-frame of concern. If the initial set of requirements is incomplete, then the stakeholders often shift their ideas as the planning process continues. A case of “Heisenberg Uncertainty” occurs, as the analysts’ actions awaken users to new possibilities. The more that users see what is possible, the more they want it. Accordingly, it is necessary to 269 1060-3425/96 $5.00